An increasing number of mobile communication devices, which include PDAs (personal digital assistants), cell phones, two-way pagers and such like, now permit users to not only access services such as electronic mail (e-mail) but to download applications which can be run on these devices. Before a device can be used, it must be provisioned with a service profile. In the past, provisioning systems required that a dealer provision the device for the user. If the user decided to purchase a different terminal or upgrade services, the user was forced to return to the dealer to provision, or re-provision the terminal. More recent provisioning systems have made it possible to allow the user to initiate provisioning from the device.
Provisioning of services typically follows the following steps. Following manufacture of the device, an address of a registration server is stored in the device by the provider of the service or by an operator of a wireless network that the device is compatible with.
When the user first obtains the device, the user enables the communication system of the device, which in turn detects the presence of the wireless network and uses the stored registration server address to send a registration request to the registration server. The registration server, in conjunction with a provisioning server, determines whether the device may be provisioned with the associated service. If the registration request is approved, the device is provided with a service book that contains data and instructions that enable services on the device.
Once the device is enabled, the user may download and install content, including software applications, on the device, over the wireless network. Many organizations purchase or create Web-based applications for use by staff and external users. Various mechanisms for controlling access to such services are in use.
From the users perspective, installing an application on the device is simply a matter of finding an interesting application on the Web and initiating its download over the wireless network. In a typical over-the-air (OTA) mechanism as described above, the device must have software, termed a discovery application (DA), that allows the user to locate applications at a particular provisioning portal or download server (DS) on the network and to choose which applications to download. The DA may be browser-based or a native application, as long as it shares a common provisioning protocol with the download server; for example, HTTP. The DS is a host, visible in the network that typically runs a Web server and has access to a content repository. It has two main functions: it provides properly formatted menus, often written in WML or HTML, that lists the applications currently available for download, and it provides controlled access to the applications.
The content repository, as the name implies, is the repository of all the application descriptors and applications that are available for download. An OTA provisioning system typically encompasses content management and publication, access control, installation (and upgrading of versions) of applications. Content management server software manages the repository, typically a database, and supports content versioning, and ways for developers to drop their applications into the repository.
If the download server supports access control, the provisioning server must properly authenticate users and apply access-control policies before applications are downloaded
The above describes in general an OTA provisioning infrastructure, typical in the public environment, where user credentials are tied to access control since tracking the use of applications (content), for example for billing purposes, is important.
However in some environments, this type of access control mechanism may not be practical. For example, a similar application provisioning infrastructure has been applied in corporate or retail environments Within a corporate domain in which users may be assigned roles or belong to different groups, (such as account managers, sales staff etc.). A combination of roles defines what a user can do within the corporate domain. In other words, a user's role within the corporate domain determines which applications they have access to. Typically, a domain administrator assigns these roles or rights to a user and accordingly is also tasked with managing access to applications and services in the domain. Once a device is initially provisioned, credentials are exchanged between the device and server to authenticate the user, who is then authorized, based on their rights and roles, to access various applications, some of which may be outside the corporate domain. This is called role-based authorization, which determines the applications and services he/she is entitled to.
Furthermore as new applications are made available in the corporate domain, a user's credentials must be accessed to update his or her corresponding roles with the appropriate new applications to which they are entitled. With a domain having a large number of users, typically hundreds or even thousands, this can become quite cumbersome for the domain administrator, as it does not provide a centralized point of access control by the domain administrator. This in turn limits the scalability of the infrastructure.
A similar problem exists in public network infrastructures, where rather than users having roles, there is a contractual agreement with one or more service providers that define the applications and services that he or she is entitled to.
Accordingly, there is a need for a manner of controlling access to downloadable network resources, while providing expandability, automation, and ease of administration.